Nowadays, NFC-enabled mobile devices are capable of offering services which traditionally have been offered by smart cards. Conventionally, dedicated smart cards were designed for a single service or a limited number of services. However, an NFC-enabled mobile device typically hosts many services, some of which may be subject to security requirements. Although it appears to the end-user that all these services are offered by a single device, there is typically a plurality of resources embedded in such a device, and each of said resources is capable of offering a particular service. More specifically, a particular service typically corresponds to a resource consisting of a specific operating system comprised in a specific secure element. The NFC-enabled mobile device may comprise many different combinations of operating systems and secure elements. In the following, some exemplary use cases will be described. For the meaning of the acronyms used herein, reference is made to the appended list of acronyms.
In a first use case scenario, an end-user explicitly selects a single service from multiple services. For example, for use in an office, a printer application stores the print spool key for a printer on an emulated MFULC Tag in his mobile phone. This printer need not be subject to strict security requirements, for example. The emulated MFULC Tag may be regarded as a secure element. The printer application stores the print spool key for a more secure printer on an emulated MFULC Tag in the UICC of his mobile phone. Work area access information and keys are stored on an emulated MFDF Tag in the UICC of his mobile phone. Car door access keys are stored on an emulated HID Tag in the UICC of his mobile phone. Car infotainment preferences are stored on an emulated MFUL Tag in his mobile phone. Furthermore, a wallet application is provisioned on a so-called “FastPay” operating system in a multi-application “SmartMX” chip in his mobile phone. Furthermore, home door access keys are stored on a MFDF Tag in the multi-application “SmartMX” chip. TV Preferences are stored on an emulated FeliCa Tag in his mobile phone. Video on Demand keys are provisioned by an STB provider on an emulated MFP Tag in the UICC of his mobile phone. Favorite playlist information for his audio system are stored on an emulated Type 1 Tag on his mobile phone. Metro prepaid ticket is stored on a emulated SCOSTA Tag on the SD Card of the mobile phone. Finally, a meal pass (canteen payment application) is stored on an emulated MFUL on the SD Card of the mobile phone.
In a second use case scenario, an end-user explicitly selects a sequence of services to complete a particular transaction. For example, a secure printer may require the following interdependent services corresponding to different combinations of operating systems and secure elements of the mobile phone. First, the user's access information stored in an emulated MFDF Tag in the UICC of his mobile phone is authenticated by an NFC reader embedded in said printer. If the authentication is successful, the NFC reader will continue to authenticate the user's print key stored in an emulated MFULC in the UICC of his mobile phone. In another example, a POS may require the following independent services corresponding to different combinations of operating systems and secure elements of the mobile phone. First, the POS authenticates and transacts with a so-called “Sodexo Pass” application stored in an SD Card of the mobile phone. Subsequently and independent thereof, the POS authenticates and transacts with a “VISA Wallet” application in a “SmartMX” chip embedded in the mobile phone. In yet another example, a car door reader may require the following interdependent services corresponding to different combinations of operating systems and secure elements of the mobile phone. First, a user's access key for opening the car, which is stored in an emulated HID Tag in the UICC of his mobile phone, is authenticated by the reader. If the authentication is successful, the reader reads car infotainment preferences stored an emulated MFUL Tag in the mobile phone.
In an NFC system NFC readers are devices which provide a means to exercise a service or services offered by smart cards or NFC-enabled mobile devices. Such NFC readers could be dedicated for offering a single service, a plurality of services or a plurality of interlinked services. An NFC reader typically scans/looks for a smart card or an NFC-enabled mobile device which comes into proximity, and which supports a specific communication protocol and operating system. When a communication channel has been established, the NFC reader uses operating system specific commands to exercise the service it is defined for, without knowing a priori whether such service is hosted by the smart card or the NFC-enabled mobile device. In the following, some exemplary NFC reader service use cases will be described.
In a first use case an NFC reader is used for accessing a transport service, such as a bus or a train. Entry and exit are defined to exercise the specific transport service present on a smart card or an NFC-enabled mobile device.
In a second use case an NFC reader which is used for office access may be defined to support multiple services, such as providing access to the printer room and presenting the print spool key to the printer, present on the smart card or the NFC Enabled device. Another example of this may be an NFC reader-based car access system exercising, on the smart card or NFC-enabled mobile device, the car access information and the user preferences for the car audio settings.
In a third use case an NFC reader used at the Point of Sale in a shop may be defined to exercise multiple interlinked services such as payment, loyalty card update and discount coupons processing, distributed over different operating systems present on the smart card or NFC-enabled mobile device.
FIG. 1A illustrates a typical NFC system comprising an NFC-enabled mobile device or a smart card hosting a service or plurality of services as described above, and an NFC reader which exercises a single service or a plurality of services.
FIG. 1B illustrates a typical system architecture of an NFC-enabled mobile device. The NFC-enabled mobile device 100 comprises an NFC controller 102, a host CPU 104, a UICC 106, an SD Card 108, non-secure Flash memory 110, secure Flash memory 112, and a “SmartMX” chip 114. The NFC-enabled mobile device 100 typically supports a plurality of services. These services are referred to as “proximity services” because they are based on NFC technology. In this context, a proximity service corresponds to a specific operating system running on a specific secure element comprised in the NFC-enabled mobile device 100. FIG. 1B clearly shows that many different combinations of operating systems and secure elements are possible. For example, two different operating systems (a “FastPay” OS and an MFDF EV1 Tag OS) may run on a single secure element (the “SmartMX” chip 114). In another example, the same operating system (an emulated MFULC Tag OS) may run on different secure elements (the UICC 106 and the secure Flash memory 112). In another example, two different operating systems (an emulated SCOSTA Tag OS and an emulated FeliCa Tag OS) may run on different secure elements (the SD Card 108 and the secure Flash memory 112). The skilled person will appreciate that a secure element may also include a combination of hardware components. For example, the host CPU 104 and the SD Card 108 together may be regarded as a single secure element.
As a result of the various combinations of operating systems and secure elements required to offer a plurality of services, several problems arise. For example, an end-user may have to select a particular proximity service on the NFC-enabled mobile device manually before tapping on to a reader, which is not convenient. Furthermore, an end-user may have to know a sequence of proximity services required to perform a certain transaction, if said transaction involves the use of multiple services. Furthermore, the NFC reader scans for the defined protocol and operating system. It does not have a means to know and activate the secure element hosting the expected service before requesting the service. An example has been described above: a POS may authenticate and transact with a so-called “Sodexo Pass” application stored in an SD Card of the mobile phone, and subsequently and independent thereof, the POS may authenticate and transact with a “VISA Wallet” application in a “SmartMX” chip embedded in the mobile phone. This may result in exposure of security-sensitive personal data of the end-user. Furthermore, the end-user must select each proximity service manually in the correct order, which is not convenient and results in a longer transaction execution time. If the proximity services in a sequence required to perform a certain transaction are interdependent, then the additional problem arises that an end-user may have to wait for a notification about the success of a first proximity service of the sequence before he/she can select a next proximity service. In general, these problems negatively affect the user experience.